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Extension Registry for the Extensible Provisioning Protocol 
Abstract 

The Extensible Provisioning Protocol (EPP) includes features to add 
functionality by extending the protocol. It does not, however, 
describe how those extensions are managed. This document describes a 
procedure for the registration and management of extensions to EPP, 
and it specifies a format for an IANA registry to record those 
extensions. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7451. 


Copyright Notice 


Copyright (c) 2015 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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1. Introduction 


Domain name registries implement a variety of operational and 
business models. The differences in these models make it impossible 
to develop a "one size fits all" provisioning protocol; the 
Extensible Provisioning Protocol [RFC5730] was designed to focus on a 
minimal set of common functionality with built-in extension 
capabilities that allow new features to be specified on an "as 
needed" basis. Guidelines for extending EPP are documented in RFC 
3735 [RFC3735]. 


RFCs 3735 and 5730 do not describe how extension development can be 
managed and coordinated. This has led to a situation in which server 
operators can develop different extensions to address similar needs, 
such as the provisioning of Value Added Tax (VAT) information. 
Clients then need to support multiple extensions that serve similar 
purposes, and interoperability suffers as a result. 


An IANA registry can be used to help manage and coordinate the 


development of protocol extensions. This document describes an IANA 
registry that will be used to coordinate the development of EPP 
extensions. 
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2. Extension Specification and Registration Procedure 


This section describes the format of an IANA registry and the 
procedures used to populate and manage registry entries. 


2.1. Extension Specification 


This registry uses the "Specification Required" policy described in 
RFC 5226 [RFC5226]. An English language version of the extension 
specification will be referenced from the registry, though non- 
English versions of the specification may also be provided. Note 
that Section 2.1 of RFC 3735 [RFC3735] provides specific guidelines 
for documenting EPP extensions. 


Note that the "Specification Required" policy implies review by a 
"designated expert". Section 3 of RFC 5226 [RFC5226] describes the 
role of designated experts and the function they perform. 


2.1.1. Designated Expert Evaluation Criteria 


A high-level description of the role of the designated expert is 
described in Section 3.2 of RFC 5226 [RFC5226]. Specific guidelines 
for the appointment of designated experts and the evaluation of EPP 
extensions are provided here. 


The IESG should appoint a small pool of individuals (perhaps 3 - 5) 
to serve as designated experts, as described in Section 3.2 of RFC 
5226 [RFC5226]. The pool should have a single administrative chair 
who is appointed by the IESG. The designated experts should use the 
existing eppext mailing list (eppext@ietf.org) for public discussion 
of registration requests. This implies that the mailing list should 
remain open after the work of the EPPEXT working group has concluded. 


Extensions should be evaluated for architectural soundness using the 
guidelines described in RFC 3735 [RFC3735], including the Security 
Considerations section of that document. Expert evaluation should 
explicitly include consideration of the privacy consequences of 
proposed extensions, and, at a minimum, ensure that any privacy 
considerations are fully documented in the relevant specification(s). 


The results of the evaluation should be shared via email with the 
registrant and the eppext mailing list. Issues discovered during the 
evaluation can be corrected by the registrant, and those corrections 
can be submitted to the designated experts until the designated 
experts explicitly decide to accept or reject the registration 
request. The designated experts must make an explicit decision and 
that decision must be shared via email with the registrant and the 
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eppext mailing list. If the specification for an extension is an 
IETF Standards Track document, no review is required by the 
designated expert. 


Designated experts should be permissive in their evaluation of 
requests to register extensions that have been implemented and 
deployed by at least one registry/registrar pair. This implies that 
it may indeed be possible to register multiple extensions that 
provide the same functionality. Requests to register extensions that 
have not been deployed should be evaluated with a goal of reducing 
functional duplication. A potential registrant who submits a request 
to register a new, un-deployed extension that includes similar 
functionality to an existing, registered extension should be made 
aware of the existing extension. The registrant should be asked to 
reconsider their request given the existence of a similar extension. 
Should they decline to do so, perceived similarity should not be a 
sufficient reason for rejection as long as all other requirements are 
met. 


2.2. Registration Procedure 


The registry contains information describing each registered 
extension. Registry entries are created and managed by sending forms 
to IANA that describe the extension and the operation to be performed 
on the registry entry. 


2.2.1. Required Information 


Name of Extension: A case-insensitive, ASCII text string that 
contains the name of the extension specification. Non-ASCII 
representations of the extension name can be included in the "Notes" 
described below. 


Document Status: The document status ("Informational", "Standards 
Track", etc.) of the specification document. For documents that are 
not RFCs, this will always be "Informational". 


Reference: A publicly available reference to the specification of 
this extension. This could be an RFC number or some other pointer to 
the document defining the extension. 


Registrant Name and Email Address: The name and email address of the 
person that is responsible for managing the registry entry. If the 
registration is of an IETF Standards Track document, this can simply 
be listed as "IESG, <iesg@ietf.org>". 
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TLDs: A text string containing the top-level domain name (or domain 
names), including the preceding ".", for which the extension has been 
specified (e.g., ".org"). If there are multiple TLDs, they are given 
as a list of domain names separated by commas, (e.g. ".com", ".net"). 
Internationalized Domain Name (IDN) TLDs should be specified in 
A-label [RFC5890] format. If the extension is not associated with a 
specific top-level domain, the case-insensitive text string "Any" can 
be used to indicate that. 


IPR Disclosure: A pointer to any Intellectual Property Rights (IPR) 
disclosure document(s) related to this extension, or "None" may be 
used if there are no such disclosures. This can be an IPR disclosure 
filed with the IETF in accordance with RFC 3979 [RFC3979] as updated 
by RFC 4879 [RFC4879] if the extension is part of an IETF 
Contribution, or it can be other IPR disclosure documents identifying 
the claimed intellectual property rights and terms of use for 
extensions that are not part of an IETF Contribution. 


Status: Either "Active" or "Inactive". The "Active" status is used 
for extensions that are currently implemented and in use. The 
"Inactive" status is used for extensions that are not implemented or 
are otherwise not being used. 


Notes: Either "None" or other text that describes optional notes to 
be included with the registered extension. If the Status value is 
"Inactive", text should be included to describe how and when this 
state was reached. 
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2.2.2. Registration Form 
The required information must be formatted consistently using the 


following registration form. Form field names and values may appear 
on the same line. 


Name of Extension: 

<text string> (quotes are optional) 
Document Status: <document status> 
Reference: <RFC number, URL, etc.> 


Registrant Name and Email Address: 
<registrant name>, <email address> 


TLDs: "Any" |<one or more TLD text strings separated by commas> 
IPR Disclosure: "None" |<URL> 


Status: "Active" |"Inactive" 
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Example form with RFC specification: 
Name of Extension: 


"An Extension RFC for the Extensible Provisioning Protocol (EPP)" 


Document Status: 
Standards Track 


Reference: 
RFC XXXX 


Registrant Name and Email Address: 
IESG, <iesg@ietf.org> 


TLDs: Any 
IPR Disclosure: None 
Status: Active 


Notes: None 


Name of Extension: 
"An Example Extension for the .example Top-Level Domain" 


Document Status: 
Informational 


Reference: 
http://www.example.com/html/example-epp-ext.txt 


Registrant Name and Email Address: 
John Doe, jdoe@example.com 


TLDs: .example 


IPR Disclosure: 
http://www.example.com/ipr/example-epp-ext-ipr.html 


Status: Active 


Notes: None 
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2.2.3. Registration Processing 


Registrants should send each registration form to IANA with a single 
record for incorporation into the registry. Send the form via email 
to <iana@iana.org> or complete the online form found on the IANA web 
site. The subject line should indicate whether the enclosed form 
represents an insertion of a new record (indicated by the word 
"INSERT" in the subject line) or a replacement of an existing record 
(indicated by the word "MODIFY" in the subject line). At no time can 
a record be deleted from the registry. On receipt of the 
registration request, IANA will initiate review by the designated 
expert(s), who will evaluate the request using the criteria in 
Section 2.1.1 in consultation with the eppext mailing list. 


2.2.4. Updating Registry Entries 


When submitting changes to existing registry entries, include text in 
the "Notes" field of the registration form describing the change. 
Under normal circumstances, registry entries are only to be updated 
by the registrant. If the registrant becomes unavailable or 
otherwise unresponsive, the designated expert can submit a 
registration form to IANA to update the registrant information. 
Entries can change state from "Active" to "Inactive" and back again 
as long as state-change requests conform to the processing 
requirements identified in this document. In addition to entries 
that become "Inactive" due to a lack of implementation, entries for 
which a specification becomes consistently unavailable over time 
should be marked "Inactive" by the designated expert until the 
specification again becomes reliably available. 


3. IANA Considerations 


IANA has created the "Extensions for the Extensible Provisioning 
Protocol (EPP)" registry to manage EPP extensions. This registry has 
its own heading on IANA’s protocol listings. The information to be 
registered and the procedures to be followed in populating the 
registry are described in Section 2. 


Name of registry: Extensions for the Extensible Provisioning Protocol 
(EPP) 


Section at http://www.iana.org/protocols: 
Registry Title: Extensions for the Extensible Provisioning 
Protocol (EPP) 
Registry Name: Extensions for the Extensible Provisioning 
Protocol (EPP) 
Registration Procedure: Specification Required 
Reference: this document 
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Required information: See Section 2.2.1. 


Review process: "Specification Required" as described in RFC 5226 
[RFC5226]. 


Size, format, and syntax of registry entries: See Section 2.2.1. 
Initial assignments and reservations: 


----- BEGIN FORM----- 

Name of Extension: 

"Domain Registry Grace Period Mapping for the 
Extensible Provisioning Protocol (EPP)" 


Document Status: 
Standards Track 


Reference: 
RFC 3915 


Registrant Name and Email Address: 
IESG, <iesg@ietf.org> 


TLDs: Any 
IPR Disclosure: None 
Status: Active 


Notes: None 
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Name of Extension: 
"E.164 Number Mapping for the 
Extensible Provisioning Protocol (EPP)" 


Document Status: 
Standards Track 


Reference: 
RFC 4114 


Registrant Name and Email Address: 
IESG, <iesg@ietf.org> 


TLDs: Any 
IPR Disclosure: None 
Status: Active 


Notes: None 


Name of Extension: 
"ENUM Validation Information Mapping for the 
Extensible Provisioning Protocol" 


Document Status: 
Standards Track 


Reference: 
RFC 5076 


Registrant Name and Email Address: 
IESG, <iesg@ietf.org> 


TLDs: Any 
IPR Disclosure: None 
Status: Active 


Notes: None 
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Name of Extension: 
"Domain Name System (DNS) Security Extensions Mapping for the 
Extensible Provisioning Protocol (EPP)" 


Document Status: 
Standards Track 


Reference: 
RFC 5910 


Registrant Name and Email Address: 
IESG, <iesg@ietf.org> 


TLDs: Any 

IPR Disclosure: None 
Status: Active 
Notes: None 

In addition, the form used to populate and manage the registry will 

be added to the table of Protocol Registration Forms maintained by 

IANA. 

4. Security Considerations 

This document introduces no new security considerations to EPP. 

However, extensions should be evaluated according to the Security 

Considerations of RFC 3735 [RFC3735]. 
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